home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Mar 91 / MacApp.Tech$ 3⁄8⁄91 / 3188-Another MA3 opinion -Mar91 < prev    next >
Encoding:
Text File  |  1991-04-01  |  4.9 KB  |  91 lines  |  [TEXT/GEOL]
  1. Item    2824234                         5-March-91        14:28PST
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     D4727                           Philmont SW Mill, Jesse Feiler,PAS
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    Another MA3 opinion (longer)
  11.  
  12. MacApp.Techers: I don't know whether anyone actually received the following, as
  13. I am battling a flaky modem.  Here goes again.
  14. -------------------------------------------------------------------------------
  15.  
  16. Jesse,
  17.  
  18. "'Fess up, Jeff.  Don't you (like the rest of us) leave inheritance and
  19. polymorphism in in designing the run-time environment?"  All right, I confess…
  20. I do form abstractions during analysis and design.  I do not, however, form
  21. classes until the last possible moment.  There is a subtle but important
  22. difference.  If objects X and Y share certain properties, I can describe the
  23. common features (an abstraction) during analysis and design without imposing a
  24. decision that this will ultimately translate into an ancestor class.  Why?
  25.  
  26. • There are often overlapping abstractions, not all of which can or should be
  27. reflected in a class hierarchy, which are nonetheless useful in describing the
  28. design of the program.
  29.  
  30. • A related issue is that the class hierarchy is limited by the language chosen
  31. (e.g., multiple inheritance), while abstractions are not.  Design should be
  32. language-independent wherever possible; the language and the use of its
  33. features are implementation decisions.
  34.  
  35. • There are many ways to implement abstractions.  There is a strict
  36. equivalence, from a theoretical point of view, between inheritance and
  37. communications with "helper" objects.  If class A has properties I need in an
  38. instance of class B, I can either associate an instance of A or inherit from A
  39. and achieve the same end result either way.  This is the basis of the classic
  40. multiple inheritance workaround.  I can also construct an argument that #define
  41. macros, MPW editing scripts and even simple copy-paste editing can be used to
  42. implement abstractions, independent of the class hierarchy.  And, of course, I
  43. still have IF-ELSE and CASE available (no, I don't think they've been
  44. eliminated by OOP, but that's an intriguing line of thought I'll return to
  45. shortly).  With all of these ways of implementing a single concept, I should be
  46. able to describe the concept and leave the decision of how to implement it as a
  47. separate issue.
  48.  
  49. • People deal well with abstractions, but not necessarily class hierarchies.
  50. Consult "Women, Fire and Dangerous Things" by George Lakoff if you want to see
  51. the evidence.  Classes are not really all that great at capturing semantics,
  52. even though objects are.
  53.  
  54. • Closer to home, one of the biggest benefits of MacApp is that you don't have
  55. to worry about the class library until your design is pretty well set.  When
  56. you are ready to design the class hierarchy, MacApp will be there with the
  57. right features or pretty close to it.  The analysis and design process should
  58. not be "here are the MacApp classes, what can we make of them?" but "here are
  59. the concrete objects and interface we want, what MacApp classes help us build
  60. them?"
  61.  
  62. As to your three classes of methods, how about this for an intellectual basis
  63. (I don't know how elegant, however).  There are four things you can inherit: a
  64. public interface, a private (protected, in C++ terms) interface, relationships
  65. to other objects, and behaviors (implementations of methods).  This applies to
  66. individual methods and to classes.  (Classes can also inherit data.)  Methods
  67. which MUST be overridden exist only to pass along an interface.  Methods which
  68. call INHERITED are extensions to a behavior, but leave the basic behavior
  69. intact and, by extension, also preserve relationships.  Methods which are
  70. completely overridden and do not call INHERITED are the dangerous ones and
  71. should be avoided where possible; they may or may not preserve relationships
  72. and you can't tell in advance how they will be used.  These are the "methods
  73. which may or may not be completely or partially overridden or perhaps not even
  74. called but no one can tell for sure in advance or perhaps not even in the
  75. finished program and I'm just going to chuck the whole program and go fishing."
  76.  
  77. Returning to Dijkstra, you are right that inheritance and polymorphism have the
  78. hallmarks of IF-THEN and CASE constructs, branching on the type.  However, the
  79. point about eliminating GOTOs is to limit the number of ways to reach a given
  80. line of code, thereby making it easier to prove or test correctness.  If we
  81. eliminate IF-THEN and CASE in such a way that we can't tell how a given line of
  82. code can be reached, we have jumped backward, not forward.  And I certainly
  83. take issue with the assertion that compiling and running (once) properly
  84. translates into functioning code; if anything, OOP code is MORE difficult to
  85. test, line for line, not less.
  86.  
  87. Buried in my own abstractions,
  88. I remain,
  89. Jeff Alger
  90.  
  91.